The present invention relates to the field of system networks, and, more particularly, to a method and apparatus for allocating bandwidth to systems transmitting data over a communication link in a network.
In a network, such as the Internet or an Intranet, in which many systems are coupled to each other by communication links, some links may be overused, that is, the demand for bandwidth over a particular link exceeds the bandwidth that is actually available. Often, this demand results from several data flows, possibly originating from multiple sources competing for the available bandwidth. Accordingly, it is desirable to enforce a specific policy for allocating the available bandwidth among the competing sources.
Many prior art mechanisms were developed to facilitate bandwidth allocation. In one method, the routers or switches in the network are given a bandwidth reservation by data transmitting servers, and then enforce the bandwidth allocation policy. This approach requires the implementation of a reservation and/or flow-setup protocol, which may be costly. Examples of this method include xe2x80x9cfair queuingxe2x80x9d, xe2x80x9cweighted fair queuingxe2x80x9d, xe2x80x9cvirtual clockxe2x80x9d, etc. These mechanisms are generally aimed at simple fairness among flows and will be discussed in more detail below.
In another method, the scheduler that provides CPU time to server threads is pre-programmed to give certain threads higher priority. This approach is not practical for the short data responses typically transmitted in the Internet environment. A typical data response over the Internet is between 8 Kbytes and 16 Kbytes, whereas operating systems can generally buffer 32 Kbytes or more data waiting for transmission. When a thread gets CPU time from the scheduler, it will try to push all of its data into the operating system buffer. After the data is stored in the buffer, the priorities allocated by the scheduler have no influence on the rate at which the network protocol stack transmits data out of a buffer. This approach might have some applicability for long data responses, but is ineffective in actually allocating bandwidth according to scheduling priorities. An example of this approach is described in xe2x80x9cProviding Differentiated Quality-of-Service in Web Hosting Services,xe2x80x9d by Jussara Almeida, Mihaela Dabu, Anand Manikutty and Pei Cao. Technical Report, Computer Sciences Dept, Univ. of Wisconsin-Madison, March 1998; and reprinted in the 1998 SIGMETRICS Workshop on Internet Server Performance.
In yet another method, the server application software uses a rate-limiting mechanism to control the amount of data it hands to the network protocol stack to be transmitted to the network. This approach was developed to prevent theft of information. This approach may be unreliable because in a large-scale system accurate control is very difficult. An example of this approach is described in xe2x80x9cX Through the Firewall, and Other Application Relays,xe2x80x9d by G. Winfield Treese and Alec Wolman, USENIX Summer 1993 Conference Proceedings, June 1993, pages 87-99.
All of the above described approaches are inadequate when a server wants to give higher priority to specific requests. For example, a Web proxy operator may wish to give higher priority to users of the internal network, to retrievals requested by specific users, or to retrievals from specific sites.
A server computer handles multiple data flows between itself and other devices. The server has one or more applications that allocate bandwidth to respective flows and a network protocol stack that implements those allocations. When bandwidth allocations are made in accordance with a bandwidth allocation policy, the protocol stack in the server enforces the policy. The network protocol stack provides a programming interface that allows the application to specify the bandwidth allocation for a flow. The network protocol stack then enforces this allocation unless there is no shortage of available bandwidth.
The present invention provides many advantages over the prior art method of using routers or switches to implement bandwidth allocation. In the prior art method, a router must determine a flow""s identity to implement appropriate bandwidth allocation. However, the current protocol, IPv4, does not include a flow label in each data packet; as a result, the router must infer flow identity from other packet header fields which can be a very complicated and time consuming process. On the other hand, the network protocol stack can simply tag internal packet buffers with the appropriate flow identities while implementing bandwidth allocations.
The present invention also dramatically reduces packet loss resulting from queue overflow. When bandwidth allocation is implemented by a router, frequently the router""s queues fill up, causing packet loss. Packet loss creates severe inefficiencies and delays. Using the network protocol stack to implement bandwidth allocation allows the data packets to be deferred internally (for example, by blocking an application thread) without any packet loss.
Implementing the present invention involves minimal change to existing systems, in part because it does not involve any change to network routers between sending and receiving systems, and in part because packet-scheduling decisions are made in the network protocol stack. The sending application needs little or no modification. If the sending application is modified, it simply needs to specify the target bandwidth (or a corresponding data transmission priority level) to the network protocol stack. The sending application does not need complex mechanisms to schedule data transmissions. The present invention is also xe2x80x9cwork-conservingxe2x80x9d; namely, when the link is idle, data is sent regardless of its priority.